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Abstract. We study mechanisms that permit program components to express role con- 
straints on clients, focusing on programmatic security mechanisms, which permit access 
controls to be expressed, in situ, as part of the code realizing basic functionality. In this 
setting, two questions immediately arise. (1) The user of a component faces the issue of 
safety: is a particular role sufficient to use the component? (2) The component designer 
faces the dual issue of protection: is a particular role demanded in all execution paths of 
the component? We provide a formal calculus and static analysis to answer both questions. 



This paper addresses programmatic security mechanisms as realized in systems such as 
Java Authentication and Authorization Service (jaas) and .NET. These systems enable two 
forms of access control mechanism£|. First, they permit declarative access control to describe 
security specifications that are orthogonal and separate from descriptions of functionality, 
e.g., in an interface J, a declarative access control mechanism could require the caller to 
possess a minimum set of rights. While conceptually elegant, such specifications do not 
directly permit the enforcement of access control that is sensitive to the control and dataflow 
of the code implementing the functionality — consider for example history sensitive security 
policies that require runtime monitoring of relevant events. Consequently, JAAS and .NET 
also include programmatic mechanisms that permit access control code to be intertwined 
with functionality code, e.g., in the code of a component implementing interface /. On the 
one hand, such programmatic mechanisms permit the direct expression of access control 
policies. However, the programmatic approach leads to the commingling of the conceptually 
separate concerns of security and functionality. 
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There is extensive literature on policy languages to specify and implement policies 
(e.g., [16j [28j [13 El [29j [13] to name but a few). This research studies security policies 
as separate and orthogonal additions to component code, and is thus focused on declarative 
security in the parlance of JAAS/.NET. 

In contrast, we study programmatic security mechanisms. Our motivation is to extract 
the security guarantees provided by access control code which has been written inline with 
component code. We address this issue from two viewpoints: 

• The user of a component faces the issue of safety: is a particular set of rights sufficient to 
use the component? (ie. with that set of rights, there is no possible execution path that 
would fail a security check. Furthermore, any greater set of rights will also be allowed to 
use the component) 

• The component designer faces the dual issue of protection: is a particular set of rights 
demanded in all execution paths of the component? (ie. every execution path requires 
that set of rights. Furthermore, any lesser set of rights will not be allowed to use the 
component) 

The main contribution of this paper is separate static analyses to calculate approximations 
to these two questions. An approximate answer to the first question is a set of rights, 
perhaps bigger than necessary, that is sufficient to use the component. On the other hand, 
an approximate answer to the second question, is a set of rights, perhaps smaller than what 
is actually enforced, that is necessary to use the component. 

1.1. An overview of our technical contributions. There is extensive literature on Role- 
Based Access-Control (rbac) models including NIST standards for RBAC [261 02]; see [H] f° r 
a textbook survey. The main motivation for RBAC, in software architectures (e.g., [221 [21] ) 
and frameworks such as jaas/.net, is that it enables the enforcement of security policies 
at a granularity demanded by the application. In these examples, RBAC allows permissions 
to be de-coupled from users: Roles are the unit of administration for users and permissions 
are assigned to roles. Roles are often arranged in a hierarchy for succinct representation 
of the mapping of permissions. Component programmers design code in terms of a static 
collection of roles. When the application is deployed, administrators map the roles defined 
in the application to users in the particular domain. 

In this paper, we study a lambda calculus enriched with primitives for access control, 
dubbed A-RBAC. The underlying lambda calculus serves as an abstraction of the ambient 
programming framework in a real system. We draw inspiration from the programming 
idioms in JAAS and .net, to determine the expressiveness required for the access control 
mechanisms. In a sequence of .net examples^, closely based on |18) . we give the reader a 
flavor of the basic programming idioms. 

Example 1 ( [E]). In the .NET Framework CLR, every thread has a Principal object that 
carries its role. This Principal object can be viewed as representing the user executing 
the thread. In programming, it often needs to be determined whether a specific Principal 
object belongs to a familiar role. The code performs checks by making a security call for 
a PrincipalPermission object. The PrincipalPermission class denotes the role that a 
specific principal needs to match. At the time of a security check, the CLR checks whether 

n 

In order to minimize the syntactic barrage on the unsuspecting reader, our examples to illustrate the 
features are drawn solely from the .net programming domain. At the level of our discussion, there are no 
real distinctions between jaas and .net security services. 
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the role of the Principal object of the caller matches the role of the PrincipalPermission 
object being requested. If the role values of the two objects do not match, an exception is 
raised. The following code snippet illustrates the issues: 

PrincipalPermission usrPerm = 

new PrincipalPermission (null, "Manager") ; 

usrPerm . Demand ( ) 

If the current thread is associated with a principal that has the the role of manager, the 
PrincipalPermission objects are created and security access is given as required. If the 
credentials are not valid, a security exception is raised. □ 

In this vein, the intuitive operation of A-RBAC is as follows. A-RBAC program execution 
takes place in the context of a role, say r, which can be viewed concretely as a set of 
permissions. The set of roles used in a program is static: we do not allow the dynamic 
creation of roles. A-RBAC supports run-time operations to create objects (i.e. higher-order 
functions) that are wrapped with protecting roles. The use of such guarded objects is 
facilitated by operations that check that the role-context r is at least as strong as the 
guarding role: an exception is raised if the check fails. 

The next example illustrates that boolean combinations of roles are permitted in pro- 
grams. In classical RBAC terms, this is abstracted by a lattice or boolean structure on 
roles. 

Example 2 ( |18j). The Union method of the PrincipalPermission class combines multiple 
PrincipalPermission objects. The following code represents a security check that succeeds 
only if the Principal object represents a user in the CourseAdmin or BudgetManager roles: 
PrincipalPermission Perml = 

new PrincipalPermission (null, "CourseAdmin") ; 
PrincipalPermission Perm2 = 

new PrincipalPermission (null , "BudgetManager ' ) ; 

// Demand at least one of the roles using Union 
perml. Union (perm2) .Demand () 
Similarly, there is an Intersect method to represent a "join" operation in the role lattice. □ 

In A-RBAC, we assume that roles form a lattice: abstracting the concrete union/inter- 
section operations of these examples. In the concrete view of a role as a set of permissions, 
role ordering is given by supersets, ie. a role is stronger than another role if it has more 
permissions; join of roles corresponds to the union of the sets of permissions and meet of 
roles corresponds to the intersection of the sets of permissions. Some of our results assume 
that the lattice is boolean, i.e. the lattice has a negation operation. In the concrete view 
of the motivating examples, the negation operation is interpreted by set complement with 
respect to a maximum collection of permissions 

Our study is parametric on the underlying role lattice. 

The key operation in such programming is rights modulation. From a programming 
viewpoint, it is convenient, indeed sometimes required, for an application to operate under 
the guise of different users at different times. Rights modulation of course comes in two 
flavors: rights weakening is overall a safe operation, since the caller chooses to execute with 
fewer rights. On the other hand, rights amplification is clearly a more dangerous operation. 
In the .NET framework, rights modulation is achieved via a technique called impersonation. 
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Example 3. Impersonation of an account is achieved using the account's token, as shown 
in the following code snippet: 

Windowsldentity stldentity = new Windowsldentity (StToken) ; 

// StToken is the token associated with the Windows acct being impersonated 
WindowsImpersonationContext stlmp = stldentity . Impersonate () ; 

// now operating under the new identity 
stlmp. UndoO ; // revert back 

□ 

A-RBAC has combinators to perform scoped rights weakening and amplification. 

We demonstrate the expressiveness of A-RBAC by building a range of useful combinators 
and a variety of small illustrative examples. We discuss type systems to perform the two 
analyses alluded to earlier: (a) an analysis to detect and remove unnecessary role-checks in 
a piece of code for a caller at a sufficiently high role, and (b) an analysis to determine the 
(maximal) role that is guaranteed to be required by a piece of code. The latter analysis ac- 
quires particular value in the presence of rights modulation. For both we prove preservation 
and progress properties. 

1.2. Related work. Our paper falls into the broad area of research enlarging the scope of 
foundational, language-based security methods (see [27] HH [3] for surveys). 

Our work is close in spirit, if not in technical development, to edit automata [16], which 
use aspects to avoid the explicit intermingling of security and baseline code. 

The papers that are most directly relevant to the current paper are those of Braghin, 
Gorla and Sassone [7j and Compagnoni, Garalda and Gunter [10]. [7] presents the first con- 
current calculus with a notion of RBAC, whereas [10] 's language enables privileges depending 
upon location. 

Both these papers start off with a mobile process-based computational model. Both cal- 
culi have primitives to activate and deactivate roles: these roles are used to prevent undesired 
mobility and/or communication, and are similar to the primitives for role restriction and 
amplification in this paper. The ambient process calculus framework of these papers pro- 
vides a direct representation of the "sessions" of RBAC — in contrast, our sequential calculus 
is best thought of as modeling a single session. 

[7j [10] develop type systems to provide guarantees about the minimal role required for 
execution to be successful — our first type system occupies the same conceptual space as this 
static analysis. However, our second type system that calculates minimum access controls 
does not seem to have an analogue in these papers. 

More globally, our paper has been influenced by the desire to serve loosely as a metalan- 
guage for programming RBAC mechanisms in examples such as the JAAS/.NET frameworks. 
Thus, our treatment internalizes rights amplification by program combinators and the am- 
plify role constructor in role lattices. In contrast, the above papers use external — i.e. 
not part of the process language — mechanisms (namely, user policies in [10], and rbac- 
schemes in [7]) to enforce control on rights activation. We expect that our ideas can be 
adapted to the process calculi framework. In future work, we also hope to integrate the 
powerful bisimulation principles of these papers. 

Our paper deals with access control, so the extensive work on information flow, e.g., 
see [24] for a survey, is not directly relevant. However, we note that rights amplification 
plays the same role in A-RBAC that declassification and delimited release [U EH [20] plays in 
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the context of information flow; namely that of permitting access that would not have been 
possible otherwise. In addition, by supporting the internalizing of the ability to amplify code 
rights into the role lattice, our system permits access control code to actively participate in 
managing rights amplification. 

1.3. Rest of the paper. We present the language in ISection 21 the type system in Sec- 
tion 3 and illustrate its expressiveness with examples in ISection 41 We discuss methods for 
controlling rights amplification in ISection 51 ISection 61 provides proofs of the theorems from 
ISection 3l 

2. The Language 

After a discussion of roles, we present an overview of the language design. The remaining 
subsections present the formal syntax, evaluation semantics, typing system, and some simple 
examples. 

2.1. Roles. The language of roles is built up from role constructors. The choice of role 
constructors is application dependent, but must include the lattice constructors discussed 
below. Each role constructor, k, has an associated arity, arity(K). Roles A-E have the form 

k(A\, . . . , An). 

We require that roles form a boolean lattice; that is, the set of constructors must include 
the miliary constructors and i, binary constructors U and n (written infix), and unary 
constructor * (written postfix). is the least element of the role lattice, i is the greatest 
element. I~l and U are idempotent, commutative, associative, and mutually distributive meet 
and join operations respectively. * is the complement operator. 

A role may be thought of as a set of permissions. Under this interpretation, is the 
empty set, while i is the set of all permissions. 

The syntax of terms uses role modifiers, p, which may be of the form f A or [A. We use 
role modifiers as functions from roles to roles, with p(\ A D defined as follows: 

ti|B|=4UB [A(\B)=AnB 

In summary, the syntax of roles is as follows. 

K "= | i | U | n | * | • • • Role constructors 

A-E ::= k{A\, ... , A n ) Roles 

p ::= 1A | [A Role modifiers 

Throughout the paper, we assume that all roles (and therefore all types) are well-formed, 
in the sense that role constructors have the correct number of arguments. 

The semantics of roles is defined by the relation "A = B" stating that A and B are 
provably equivalent. In addition to any application-specific axioms, we assume the standard 
axioms of boolean algebra. We say that A dominates B (notation A ^ B) if A = A Li B 
(equivalently B = A n B) is derivable. Thus we can conclude 1 ^ Au B ^ A ^ An B ^ 0, 
for any A, B. 

The role modifier J, A creates a weaker role (closer to 0), thus we refer to it as a restriction. 
Dually, the modifier |A creates a stronger role (closer to i), and thus we refer to it as an 
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amplification. While this ordering follows that of the nist rbac standard [12], it is dual to 
the normal logical reading; it may be helpful to keep in mind that, viewed as a logic, 1 is 
"false", is "true", U is "and", n is "or" and ^ is "implies." 



2.2. Language overview. Our goal is to capture the essence of role-based systems, where 
roles are used to regulate the interaction of components of the system. We have chosen to 
base our language on Moggi's monadic metalanguage because it is simple and well under- 
stood, yet rich enough to capture the key concepts. By design, the monadic metalanguage is 
particularly well suited to studying computational side effects (or simply effects), which are 
central to our work. (We expect that our ideas can be adapted to both process and object 
calculi.) 

The "components" in the monadic metalanguage are terms and the contexts that use 
them. To protect terms, we introduce guards of the form {^4} [M] , which can only be 
discharged by a context whose role dominates A. The notion of context role is formalized in 
the definition of evaluation, where A > M — > A indicates that context role A is sufficient to 
reduce M to A. The term check M discharges the guard on M. The evaluation rule allows 
A > check {By [M] -> [M] only ilA^B. 

The context role may vary during evaluation: given context role A, the term p{M) 
evaluates M with context role pfl-A|). Thus, when [B(M) is evaluated with context role A, 
M is evaluated with context role An B. A context may protect itself from a term by placing 
the use of the term in such a restricted context. (The syntax enforces a stack discipline on 
role modifiers.) By combining upwards and downwards modifiers, code may assume any role 
and thus circumvent an intended policy. We address this issue in ISection 5l 

These constructs are sufficient to allow protection for both terms and contexts: terms 
can be protected from contexts using guards, and contexts can be protected from terms 
using (restrictive) role modifiers. 



2.3. Syntax. Let x,y,z,f,g range over variable names, and let bv range over base values. 
Our presentation is abstract with respect to base values; we use the types String, Int and 
Unit (with value unit) in examples. We use the standard encodings of booleans and pairs 
(see |Example 14 ). The syntax of values and terms are as follows. 



V,U,W "= M, N, L ::= Values; Terms 

bv | x V Base Value 

Xx.M MA | fix M Abstraction 

■U} [M] check M Guard 

[M] let x=M; N Computation 

p(M) Role Modifier 

Notation. In examples, we write A(M) to abbreviate J.0(|j4(M)), which executes M at 
exactly role A. 

The variable x is bound in the value "Ax. M" (with scope M) and in the term "let x=M ; 
A" (with scope N). If x does not appear free in M, we abbreviate "Ax.M" as "A.M". 
Similarly, if x does not appear free in N, we abbreviate "let x = M ; A" as "M; A". We 
identify syntax up to renaming of bound variables and write N{x := M} for the capture- 
avoiding substitution of M for x in A. □ 
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In the presentation of the syntax above, we have paired the constructors on values 
on the left with the destructors on computations on the right. For example, the monadic 
metalanguage distinguishes 2 from [2] and [1+1] : the former is an integer, whereas the 
latter are computations that, when bound, produce an integer. The computation value [M] 
must be discharged in a binding context — see the reduction rule for let, below. Similarly, 
the function value Xx.M must be discharged by application; in the reduction semantics 
that follows, evaluation proceeds in an application till the term in function position reduces 
to a lambda abstraction. {^4} [M] constructs a guarded value; the associated destructor is 
check . 

The monadic metalanguage distinguishes computations from the values they produce 
and treats computations as first class entities. (Any term may be treated as a value via the 
unit constructor [M] .) Both application and the let construct result in computations; how- 
ever, the way that they handle their arguments is different. The application "(Ax. N) [M]" 
results in N{x := [M] }, whereas the binding "let x= [M] ; M" results in N{x := M}. 

2.4. Evaluation and role error. The small-step evaluation relation A > M — > M' is 
defined inductively by the following reduction and context rules. 

(C-APP) 

(r-app) A> M -> M' 



A > (Xx. M) N — > M{x := N} A> M N -» M' N 

(C-FIX) 

(r-fix) A> M -> M' 



A > fix (Ax. M) -> M{x := fix (Ax. M)} A > fix M -> fix M' 

(c-chk) 

(r-chk) A>M -> M' 

A > B 



A > check {B} [M] — > [M] A > check M -» check M' 

(c-bind) 

(r-bind) A> M M' 



A > let x= [M] ; TV -> iV{x := M} A > let x= M ; N -> let x= M' ; N 

(c-mod) 

(r-mod) 



A>p(V)^V A>p(M)^p(M') 

The rules r/c-app for application, r/c-fix for fixed points and r/c-bind for let are 
standard. R-CHK ensures that the context role is sufficient before discharging the relevant 
guard. C-MOD modifies the context role until the relevant term is reduced to a value, at 
which point R-MOD discards the modifier. 

The evaluation semantics is designed to ensure a role-monotonicity property. Increasing 
the available role-context cannot invalidate transitions, it can only enable more evolution. 

Lemma 4. If B > M -> M' and A^ B then A> M -> M' . □ 

Proof. (Sketch) The context role is used only in R-CHK. Result follows by induction on the 
evaluation judgement. □ 
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Via a series of consecutive small steps, the final value for the program can be determined. 
Successful termination is written A > M -» V which indicates that A is authorized to run 
the program M to completion, with result V. Viewed as a role-indexed relation on terms, 
— » is reflexive and transitive. 

Definition 5. (a) Mq evaluates to M n at A (notation A > M$ -» M n ) if there exist terms 
Mi such that A > M% — > M i+1 , for all i (0 < i < n — 1). (b) M diverges at A (notation 
A > M if there exist terms Mj such that A > M { -> M i+1 , for all i G N. □ 

Evaluation can fail because a term diverges, because a destructor is given a value of the 
wrong shape, or because an inadequate role is provided at some point in the computation. 
We refer to the latter as a role error (notation A > M i err), defined inductively as follows. 

i 1 

p(\ A D > M i err 
A y B ' 



A > check {B} [M] £ err ^ A > p(M) i err 

A> M i err A> M £ en A> M i err i>Mi err 



A > M iV i err ^ > fix M i err A > let x= M ; N £ err A > check M i err 

Example 6. Recall from ISection 2.31 that B(M) abbreviates J,0(|B(M)), and define 
test<B> as follow^. 

test<B> = check {B}[unit] 

test<B> is a computation that requires context role B to evaluate. For example, J,B* (test<B>) 
produces a role error in any context, since |B* restricts any role-context to the negation of 
the role B. □ 

Example 7. We now illustrate how terms can provide roles for themselves. Consider the 
following guarded function: 

from<A,B> = {A} [Ay.B(y)] 

from<A,B> is a guarded value that may only be discharged by A, resulting in a function 
that runs any computation at B. Let test<B> = check {B}[unit]. No matter what the 
relationship is between A and B, the following evaluation succeeds: 

A > let z= check from<A , B> ; z test<B> -» B (test<B>) -» [unit] 

from<A,B> is far too powerful to be useful. After the A-guard is discharged, the resulting 
function will run any code at role B. One can provide specific code, of course, as in Ay . B (M) . 
Such functions are inherently dangerous and therefore it is desirable constrain the way in 
which such functions are created. The essential idea is to attach suitable checks to a function 
such as Ag. Ay. B (g y) , which takes a non-privileged function and runs it under B. There 
are a number of subtleties to consider in providing a general purpose infrastructure to create 
terms with rights amplification. When should the guard be checked? What functions should 



be allowed to run, and in what context? In Example 21 we discuss the treatment of these 



issues using the Domain and Type Enforcement access control mechanism. □ 



3 We do not address parametricity here; the brackets in the names test<B> and from<A,B> are merely 
suggestive. 
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3. Typing 

We present two typing systems that control role errors in addition to shape errors. 

The first typing system determines a context role sufficient to avoid role errors; that 
is, with this role, there is no possible execution path that causes a role error. This system 
enables the removal of unnecessary role-checks in a piece of code for a caller at a sufficiently 
high role. 

The second system determines a context role necessary to avoid role errors; that is, any 
role that does not dominate this role will cause every execution path to result in a role error. 
Stated differently, the second system calculates the role that is checked and tested on every 
execution path and thus determines the amount of protection that is enforced by the callee. 

Technically, the two systems differ primarily in their notions of subtyping. In the absence 
of subtyping, the typing system determines a context role that is both necessary and sufficient 
to execute a term without role errors. 

Because it clearly indicates the point at which computation is performed, the monadic 
metalanguage is attractive for reasoning about security properties, which we understand as 
computational effects. The type [T] is the type of computations of type T. We extend the 
computation type [T] to include an effect that indicates the guards that are discharged during 
evaluation of a term. Thus the term check {^4} [1+1] has type (A)[lnt] — this type indicates 
that the reduction of the term to a value (at type Int) requires A. Guarded values inhabit 
types of the form {A}[T] — this type indicates the protection of A around an underlying 
value at type T. These may be discharged with a check, resulting in a term inhabiting the 
computation type (A)[T]. 

The syntax of types is given below, with the constructors and destructors at each type 



T,S ■■■= V,U,W "= M,N,L ::= Types; Values; Terms 

Base bv \ x V Base Value 

T^S Xx.M M N | fix M Abstraction 

{A}[T} -WHM] check M Guard 

(A)[T\ [M] \etx=M;N Computation 

p(M) Role Modifier 



3.1. Subtyping. The judgments of the subtyping and typing relations are indexed by a 
which ranges over {1,2}. The subtyping relation for (A)[T] reflects the difference between 
the two type systems. 

If role A suffices to enable a term to evaluate without role errors, then any higher role 
context also avoids role errors (using ILemma 4l) . This explains the subtyping rule for the 
first type system — in particular, h x (-A)[T] <: (1)[T], reflecting the fact that the top role is 
sufficient to run any computation. 

On the other hand, if a role A of the role-context is checked and tested on every execution 
path of a term, then so is any smaller role. This explains the subtyping rule for the first 
type system — in particular, h, (A)[T] <: (0)[T], reflecting the fact that the bottom role is 
vacuously checked in any computation. 
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h T <: T' 



if a = 1 then A' ^ A 



h Q Base <: Base h Q {A}[T] <: {A 1 } [T'] if Q = 2 then A > 4' 

^ T" <: T \- a S <: S' h a T <:T' if a = 1 then A' ^ A 

h a T^S<:T'^S' \~ a (A) [T] <: (A') [T] if a = 2 then A > A' 

Lemma 8. The relations \- a T <: S are reflexive and transitive. □ 



3.2. Type systems. Typing is denned using environments. An environment, 

r .. — : T\ , . . . , x n : r n 

is a finite partial map from variables to types. 

As usual, there is one typing rule for each syntactic form plus the rule T-SUB for sub- 
sumption, which allows the use of subtyping. Upwards and downwards role modifiers have 
separate rules, discussed below. The typing rules for the two systems differ only in their no- 



tion of subtyping and in the side condition on T-MOD-DN; we discuss the latter in Example 15 



(t-sub) 

(t-base) (t-var) r \~ a M 



T\- a bv: Base T,x:T,T' h a x : T T h a M : T 



k T <: T' 



(t-abs) (t-app) (t-fix) 

T,x:ThM:S T ^ M : T -> S T ^ N : T T \- a M : T 



£ dom(T) 



Th a \x.M:T^S T h a M N : S Th a f\xM:T 

(t-grd) (t-chk) 
rh n M:T rh«Af:{A}[T] 



T h Q {,4} [M] : {A}[T\ r h a check M : (A)[T] 

(t-unit) (t-bind) 

r h a M : T rh a M : (A)[T\ T,x:T \- a N : (B)[S] 



T h Q [M] : (0)[T] r h a let x= M; N : (A U B)[S] 



x $ dom(T) 



(t-mod-up) (t-mod-dn) 

ThM:(B)[T] ThM:(B)[T] 



T h Q ]A (M) : (B n A*) [T] T h a [A (M) : (B) [T] 



if a = 1 then A > B 



The rules T-BASE, T-VAR, T-SUB, T-ABS, T-APP and T-FIX are standard. For example, 
the identity function has the expected typing, \- a Xx.x :T-*T, for any T. Nonterminating 
computations can also be typed; for example, \- a fix (Ax. x) : T, for any T. 

Any term may be injected into a computation type at the least role using t-unit. Thus, 
in the light of the earlier discussion on subtyping, if \~ a M : T then, in the first system, [M] 
inhabits (A)[T] for every role A; in the second system, the term inhabits only type (0)[T], 
indicating that no checks are required to successfully evaluate the value [M] . 
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Computations may be combined using t-bine@. If M inhabits (A)[T] and N inhabits 
(B)[S\, then "M; N" inhabits (A U B)[S]. More generally, we can deduce: 

Y- a Ax. let x'=x; x' : (A)[(B)[T]\ (A U B) [T] 

In the first type system, this rule is motivated by noting that the role context A U B suffices 
to successfully avoid role errors in the combined computation if A (resp. B) suffices for M 
(resp. N). For the second type system, consider a role C that is not bigger than AlA B — 
thus C is not bigger than at least one of A, B. If it is not greater than A, by assumption on 
typing of M , every computation path of M in role context C leads to a role-error. Similarly 
for B. Thus, in role context C, every computation path in the combined computation 
leads to a role error. Furthermore, using the earlier subtyping discussion, the sequence also 
inhabits (1)[S] in the first system and (0)[5] in the second. 

The rule t-grd types basic values with their protection level. The higher-order version 
of {A} [] has the natural typing: 

h Q Ax.{A}[x] :T^{A}[T] 

Recall that in the transition relation, check {^4} [iV] checks the role context against A. The 
typing rule T-CHK mirrors this behavior by converting the protection level of values into 
constraints on role contexts. For example, we have the typing: 

h Q Ax. check x : {A}[T} -> (A)[T] 

In the special case of typing T h a check {A}[N~\ : (_A)[T], we can further justify in the two 
systems as follows. In terms of the first type system, the role context passes this check if it 
is at least A. In terms of the second type system, any role context that does not include A 
will cause a role-error. 

Role modifiers are treated by separate rules for upwards and downwards modifiers. 

The rule for T-MOD-UP is justified for the first type system as follows. Under assumption 
that B suffices to evaluate M without role-errors, consider evaluation of ]A (M) in role 
context B\lA*. This term contributes A to role context yielding A\J(B\1 A*) = (A\JB)n 
(A U A*) = B for the evaluation of M. For the second type system, assume that if a role is 
not greater than B, then the evaluation of N leads to a role error. Consider the evaluation 
of 1A(M) in a role context C that does not exceed B n A*. Then, the evaluation of M 
proceeds in role context C \J A which does not exceed B and hence causes a role error by 
assumption. 

The rule for t-mod-dn is justified for the first type system as follows. Under assumption 
that B suffices to evaluate M without role-errors, and A is greater than B consider evaluation 
of [A (M) in role context B. This term alters role-context B to BnA = B for the evaluation 
of M, which suffices. For the second type system, assume that if a role is not greater than 
B, then the evaluation of N leads to a role error. Consider the evaluation of [A (M) in a 
role context C that does not exceed B. Then, C\lA certainly does not exceed B and so the 
evaluation of M causes a role error by assumption. 



Example 16| and |Example 15| discuss alternate presentations for the rules of typing for 
the role modifiers. 

In stating the results, we distinguish computations from other types. ILemma TUI holds 
trivially from the definitions. 



4 The distinction between our system and dependency-based systems can be see in t-bind, which in dcc 
HE] [30] states that h \etx=M; N : {B)[S} if B > A, where h M : (A)[T] and x:T h N : (B)[S\. 
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Definition 9. Role A dominates type T (notation A > T) if T is not a computation type, 
or T is a computation type {B)[S] and A^ B. □ 

Lemma 10. (a) If A^ B and B >T then A>T. (b) Ifh T <: S and A> S then A>T. 
(c) If h 2 T <: S and A>T then A>S. □ 

The following theorems formalize the guarantees provided by the two systems. The 
proofs may be found in ISection 6l 

Theorem 11. If h M : T and A > T , then either A> M —> u or A> M -» V for some V. 

Theorem 12. If h, M : T and A ^ T , then either A> M — > u or there exists N such that 
A > M -» N and A\> N i err. 

For the first system, we have a standard type-safety theorem. For the second system, 
such a safety theorem does not hold; for example h, check -Cl> [unit] : (l)[Unit] and 1 > 
check {l}[unit] — > [unit] but \/ 2 [unit] : (l)[Unit]. Instead [Theorem 121 states that a term 
run with an insufficient context role is guaranteed either to diverge or to produce a role 
error. 

3.3. Simple examples. 

Example 13. We illustrate combinators of the language with some simple functions. The 
identity function may be given its usual type: 

\- a Ax . x : T -> T 

The unit of computation can be used to create a computation from any value: 

h Q Ax. [x] : T -><(>) [T] 

The let construct evaluates a computation. In this following example, the result of the 
computation x' must itself be a computation because it is returned as the result of the 
function: 

h Q Ax. let x'=X;x' : (A)[(B)[T]] -> (A U B)[T] 

The guard construct creates a guarded term: 

h Q Ax.{A}[x] :T^{A}[T] 

The check construct discharges a guard, resulting in a computation: 

h Ax. check x : {A}[T] -» (A)[T] 

The upwards role modifier reduces the role required by a computation. 

h Q Ax.TB(x) : (A)[T]^(AnB*)[T] 

The first typing system requires that any computation performed in the context of a down- 
ward role modifier |B() must not require more than role B: 

h a Ax. |B (X) : (A) [T] -> (A) [T] (where B ^ A if a = 1) 

In the first type system, the last two judgments may be generalized as follows: 

h 1 Ax.p(x):(HA^)[T]-(A)[T] 

Thus a role modifier may be seen as transforming a computation that requires the modifier 



into one that does not. For further discussion see Example 16 □ 
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Example 14 (Booleans). The Church Booleans, tru = At. Af . t and fls = At. Af. f, illustrate 
the use of subtyping. In the two systems, these may be given the following types. 

Booli = (A) [T] -» (B) [T] -+{A\JB) [T] h tru, fls : Bool! 

Bool 2 = {A) [T] -» (B) [T] -» (A n B) [T] h 2 tru, fls : Bool 2 

These types reflect the intuitions underlying the two type systems. The first type system 
reflects a "maximum over all paths" typing, whereas the second reflects a "minimum over all 
paths" typing. The conditional may be interpreted using the following derived rules. 

rhLrBooli V h M : (A)[T] T h N : (B)[T] 



T h if L then M else N : {A U B)[T] 
rh 2 L:Bool 2 rh 2 M:{A)[T] T h 2 N : (B)[T] 
T h if L then M else N : (A n B)[T] 



□ 



Example 15 (t-mod-dn). The side condition on T-MOD-DN does not effect typability in 
second typing system, but may unnecessarily decrease the accuracy of the analysis, as can 
be seen from the following concrete example. 
Let M, N be terms of type (B)[T}. 

T \- a M : (B)[T] 

T \- a M : (An B)[T] (T_SUB) 

(t-mod-dn) 



rh„ IA(M) : (AnB)[T\ 

With the side condition, the term let x= [A(M) ; N would have to be given a type of the 
form (An B)[T], even though both M and N have type (B)[T]. Without the side condition, 
the "better" type (B)[T] may be given to the entire let expression. □ 

Example 16 (Alternative rule for role modifiers). In the first typing system, T-MOD-UP 
and t-mod-dn may be replaced with the following rule, which we call t-mod-*. 

Th M: (p<\B\)}[T} 

Th p(M) : (B) [T] 

Consider p = }A. Because C ^ (A U C) n A* , the following are equivalent. 

rh,M: (AUC)[T] 



(t-mod-up) 



Th M : (An C)[T] V h ]A(M) : ((A U C) n A*)[T] 

(t-mod-*) — — - — (t-sub) 



r h ]A{M) : (C)[T\ y ~ ' T h x ]A{M) : (C)[T] 

Because (D n A*) U A ^ D, the following are equivalent. 
ThM:(D)[T\ 

r h M : ((D n A*) U A)[T] {T ' SVB> T h M : (D)[T] 

; — — — (T-MOD-*) ; — — - (T-MOD-UP) 

r h ]A (M) : (D n A) [T] y ' T h ]A{M) : (D n A*)[T] y ' 

Consider p = [A. Because A ^ A n C and C^AnC, the following are equivalent. 

r h M : (AnC)[T] 
r h M : (A n C)[T] Th, [A{M) : (AnC)[T\ ( T " MOD - DN ) 

(T-MOD-*) — — - — : (T-SUB) 



r h IA(M) : (C)[T\ v ' Th [A{M) : (C)[T] 
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Suppose A ^ D. Then D n A ^ D, and the following are equivalent. 
ThM:(D)[T] 
ThM:(DnA)[T] (T " SUB) T \- x M : (D) [T] 

; — — - (T-MOD-*) ; — r (T-MOD-DN) U 

r hj [A(M) : (D)[T] y ' r 1-j [A(M) : (D)[T] K ' 

Example 17 (A sublanguage). The following proper sublanguage is sufficient to encode the 
computational lambda calculus. Here values and terms are disjoint, with values assigned 
value types T and terms assigned computation types (A)[T]. 



T,S 

v,u,w 

M, N,L 



Base | T^(A)[S] \ {A}[T] 
bv | x | Xx.M | {A}[V1 

[VI | VU I fixF | cheeky | let x=M;N | p(M) 



Encoding the Church Booleans in this sublanguage is slightly more complicated than in 



Example 14 tru and fls must accept thunks of type Unit-> (A) [5] rather than the simpler 
blocks of type (A) [S] . 

Operations on base values that have no computational effect are placed in the language 
of values rather than the language of terms. The resulting terms may be simplified at any 
time without affecting the computation (e.g., [1+2 == 3] may be simplified to [tru]). □ 

Example 18 (Relation to conference version). The language presented here is much simpler 
than that of the conference version of this paper [14|. In particular, the conference version 
collapsed guards and abstractions into a single form {A}[Ax.M] with types of the form 
T -> {A > fi}[5], which translates here as {A}[T -> the immediate guard of the 

abstraction is A, whereas the effect of applying the abstraction is B. 

In addition, the conference version collapsed role modification and application: the 
application [C V U first checked the guard of V, then performed the application in a 
context modified by [C. In the current presentation, this translates as "let x= check V ; 
lC(xU)." ■ - ^ 



4. Examples 

In this section we assume miliary role constructors for user roles, such as Alice, Bob, 
Charlie, Admin, and Daemon. 

Example 19 (ACLs). Consider a read-only filesystem protected by Access Control Lists 
(ACLs). One can model such a system as: 

filesystem = Aname. if name=="file1 " then check {Admin} ["datal "] 

else if name=="file2" then check {Alice n Bob} ["data2"] 
else ["error: file not found"] 

If Admin > Alice n Bob then code running in the Admin role can access both files: 

Admin > filesystem "filel " -» check {Admin} ["datal "] -» ["datal "] 
Admin > filesystem "file2" -» check {Alice n Bob} ["data2"] -» ["data2"] 

If Alice ^ Admin then code running as Alice cannot access the first file but can access the 
second: 

Alice > filesystem "filel " -» check {Admin} ["datal "] I err 

Alice > filesystem "file2" -» check {Alice n Bob} ["data2"] -» ["data2"] 
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Finally, if Charlie ^ Alice n Bob then code running as Charlie cannot access either file: 

Charlie > filesystem "filel " -» check {Admin} ["datal "] £ err 
Charlie > filesystem "file2" -» check {Alice n Bob} ["data2"] £ err 

The filesystem code can be assigned the following type, meaning that a caller must 
possess a role from each of the ACLs in order to guarantee that access checks will not fail. 
If, in addition, Admin > Alice n Bob then the final role is equal to Admin. 

h filesystem : Strings (Admin U (Alice n Bob) U 0) [String] 

In the above type, the final role arises from the "unknown file" branch that does not require 
an access check. The lack of an access check explains the weaker h 2 type: 

h 2 filesystem : Strings (Admin n (Alice n Bob) no) [String] 

This type indicates that filesystem has the potential to expose some information to unprivi- 
leged callers with role Admin n (Alice n Bob) I~l0 = 0, perhaps causing the code to be nagged 
for security review. □ 

Example 20 (Web server). Consider a web server that provides remote access to the filesys- 
tem described above. The web server can use the role assigned to a caller to access the 
filesystem (unless the web server's caller withholds its role). To prevent an attacker deter- 
mining the non-existence of files via the web server, the web server fails when an attempt is 
made to access an unknown file unless the Debug role is activated. 

webserver = Aname. if name=="file1 " then filesystem name 
else if name=="file2" then filesystem name 
else check {Debug} ["error: file not found"] 

For example, code running as Alice can access "file2" via the web server: 

Alice > webserver "file2" ^filesystem "file2" -» ["data2"] 

The access check in the web server does prevent the "file not found" error message leaking 
unless the Debug role is active, but, unfortunately, it is not possible to assign a role strictly 
greater than to the web server using the second type system. The filesystem type does not 
record the different roles that must be checked depending upon the filename argument. 

hj webserver : String -» (Admin n (Alice n Bob) nO) [String] (derivable) 

\f 2 webserver : String -» (Admin n (Alice l~l Bob) n Debug) [String] (not derivable) □ 



Example 21 illustrates how the Domain- Type Enforcement (dte) access control mecha- 



nism [SIGT], found in Security-Enhanced Linux (SELINUX) [17j . can be modelled in A-RBAC. 
Further discussion of the relationship between RBAC and DTE can be found in [TTl [T3], 

Example 21 (Domain- Type Enforcement). The DTE access control mechanism grants or 
denies access requests according to the current domain of running code. The current domain 
changes as new programs are executed, and transitions between domains are restricted in 
order to allow, and also force, code to run with an appropriate domain. The restrictions upon 
domain transitions are based upon a DTE type associated with each program to execute. For 
example, the DTE policy in |31j only permits transitions from a domain for daemon processes 
to a domain for login processes when executing the login program, because code running in 
the login domain is highly privileged. This effect is achieved by allowing transitions from 
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the daemon domain to the login domain only upon execution of programs associated with 
a particular DTE type, and that DTE type is assigned only to the login program. 

The essence of DTE can be captured in A-RBAC, using roles to model both domains and 
DTE types, and the context role to model the current domain of a system. We start by 



building upon the code fragment Ag. Ay. B(g y), discussed in Example 7 that allows a 
function checking role B to be executed in the context of code running at a different role. 
We have the typing (for emphasis we use extra parentheses that are not strictly necessary 
given the usual right associativity for the function type constructor): 

h Q Ag. Ay. B(g y) : (T -> (B)[S]) - (T -> (0)[S]) 

To aid readability, and fixing types T and S for the remainder of this example, define: 

R = R-(T-(o)[S]) 

So that the previous typing becomes: 



h Q Ag.Ay.B(gy) :T-(B)[S] 

To restrict the use of the privileged function Ag . Ay . B (g y) , it can be guarded by a role E 
acting as a DTE type, where the association of the DTE type E with a function is modelled 
in the sequel by code that can activate role E. The guarded function can be typed as: 



h Q {EHAg.Ay.B(gy)] : {E}[T -> <B)[S]] 

We now define a function domtrans<A, E, B> for a domain transition from domain (role) 
A to domain (role) B upon execution of a function associated with dte type (also a role) 
E. The function first verifies that the context role dominates A, and then permits use 
of the privileged function Ag. Ay. B(g y) by code that can activate role E. The function 
domtrans<A, E, B> is defined by: 

domtrans<A, E, B> = Af. Ax. check {A} [unit] ; f {E}[Ag. Ay. B(g y)] x 

We have the typing: 



h a domtrans<A, E, B> : {E}[T -> (B)[S]] -»• (T -> (A) [S] ) 

The above type shows that domtrans<A, E, B> can be used to turn a function checking role 
B into a function checking role A, but only when the role E is available — in contrast to the 

type (T -> (B)[S]) -»■ (T -> (A)[S]) that does not require E. 

In order to make use of domtrans<A, E, B>, we must also consider code that can activate 
E. We define a function assign<E> that takes a function f and activates E in order to access 
the privileged code Ag.Ay.B(g y) from domtrans<A, E, B>. The function assign<E> is 
defined by: 

assign<E> = Af . Ax. Ay. let g= E (check x) ; g f y 

And we have the typing: 



h Q assign<E> : (T - <B)[S]) - {E}[T -> <B)[S]] 

Therefore the functional composition of assign<E> and domtrans<A, E, B> has type: 

CT-<B)[S])-(T-><A>[S]) 

To show that in the presence of both assign<E> and domtrans<A, E, B>, code running with 
context A can execute code checking for role context B, we consider the following reductions 
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in role context A, where we take T = Az. check {B}[unit] and underline terms to indicate 
the redex: 

domtrans<A, E, B> (assign<E> J 7 ) unit 
= (Af. Ax. check {A}[unit] ; f ({E}[Ag. Ay. B(g y)]) x) (assign<E> T) unit 
-> ( Ax. check {A} [unit] ; (assign<E> J 7 ) ({E} [Ag. Ay. B (g y)] ) x ) unit 
-> check {A} [unit] ; (assign<E> T) ({E}[Ag. Ay. B (g y)]) unit 
-» ( assign<E> T) ({E} [Ag . Ay . B (g y)] ) unit 

= (( Af . Ax. Ay. let g= E (check x) ; g f y ) £) ({E}[Ag. Ay. B(g y)]) unit 

-» ( Ax.Ay.letg=E(checkx) ; g^y ) ( {E}[Ag. Ay. B(g y)] ) unit 

-» ( Ay. let g= E (check {E} [Ag . Ay . B (g y)] ) ; g T y ) unit 

-» let g = E ( check {E} [Ag . Ay . B (g y)] ) ; g T unit 

-» let g= E([Ag.Ay.B(gy)]) ; g T unit 

-» let g = [Ag. Ay. B(g y)] ; g T unit 

-> ( Ag. Ay. B(g y) ) F unit 

-» ( Ay. BCFy) ) unit 

-> BCF unit) 

= B(( Az. check {B}[unit] ) unit ) 
-> B ( check {B}[unit] ) 
-> B([unit]) 
-» [unit] 

The strength of DTE lies in the ability to factor access control policies into two compo- 
nents: the set of permitted domain transitions and the assignment of DTE types to code. 
We illustrate this by adapting the aforementioned login example from [31] to A — RBAC. In 
this example, the DTE mechanism is used to force every invocation of user code (running 
at role User) from daemon code (running at role Daemon) to occur via trusted login code 
(running at role Login). This is achieved by providing domain transitions from Login to 
User, and Daemon to Login, but no others. Moreover, code permitted to run at Login must 
be assigned dte type LoginEXE, and similarly for User and UserEXE. Thus a full program 
running daemon code M has the following form, where neither M nor N contain direct rights 
amplification. 

let dtLoginToUser= domtrans<Login, UserEXE, User>; 

let dtDaemonToLogin= domtrans<Daemon, LoginEXE, Login>; 

let shell= assign<UserEXE> (A. M) ; 

let login= assign<LoginEXE> (Apwd . if pwd=="secret" then dtLoginToUser shell unit else . . .) ; 
Daemon (N) 

Because login provides the sole gateway to the role User, the daemon code N must provide 
the correct password in order to execute the shell at User (in order to access resources that 
are available at role User but not at role Daemon). In addition, removal of the domain 
transition dtDaemonToLogin makes it impossible for the daemon code to execute any code 
at User. □ 
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5. Controlling rights amplification 

Example 22. Suppose that M contains no direct rights amplification, that is, no subterms 
of the form ]A ( ■ ) . Then, in 

let priv= [Ax. |A(V x)] ; |User(M) 

we may view V as a Trusted Computing Base (tcb) — a privileged function which may 
escalate rights — and view M as restricted user code. The function priv is an entry point to 
the TCB which is accessible to user code; that is, user code is executed at the restricted role 
User, and rights amplification may only occur through invocation of priv. 

Non-trivial programs have larger TCBs with more entry points. As the size of the TCB 
grows, it becomes difficult to understand the security guarantees offered by a system when 
rights amplification is unconstrained, even if only in the TCB. To manage this complexity, 
one may enforce a coding convention that requires rights increases be justified by earlier 
checks. As an example, consider the following, where amplify is a unary role constructor. 

let at<A>= [Af. check {amplify (A)} [Ax. |A(f x)]] ; 

let priv=at<A> V; 

|User(M) 

In a context with role amplify (A), this reduces (using r-bind, r-app and r-CHk) to 

let priv= [Ax. |A(V x)] ; |User(M) 

In a context without role amplify (A), evaluation becomes stuck when attempting to execute 
R-CHK. The privileged function returned by at<A> (which performs rights amplification for 
A) is justified by the check for amplify(A) on any caller of at<A>. 

One may also wish to explicitly prohibit a term from direct amplification of some right 
B; with such a convention in place, this can be achieved using the role modifier lamplify(B). 

□ 

One may formalize the preceding example by introducing the unary role constructor 
amplify, where amplify(A) stands for the right to provide the role A by storing ]A in code. 
We require that amplify distribute over U and n and obey the following absorption laws: 

A U amplify (A) = amplify (A) A n amplify (A) = A 

Thus amplify (A) ^ A for any role A. 

To distinguish justified use of role modifiers from unjustified use, we augment the syntax 
with checked role modifiers. 

M,N ::= ••• | p A (M) 

Whenever a check is performed on role M we mark role modifiers in the consequent to 
indicate that these modifiers have been justified by a check. Define the function mark a 
homomorphically over all terms but for role modifiers: 

markA(p(M)) = pA(markA(M)) 

markA(pB(M)) = pAuB(markA(M)) 

Modify the reduction rule for check as follows. 
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Thus, the check in the example above will execute as follows. 

amplify(A) > check {amplify (A)} [\x . |A(/x)] -> Ax. ]A amplijy{A) (/ x) 

In the residual, the abstraction contains a checked role modifier, indicating that the role 
amplification has been provided by code that had the right to do so. 

We now define role modification errors so that ]A B (M) produces an error if B does 
not dominate amplify {A). 

C ~i amplify (B) 

]B(M) I moderr ]B C (M) i moderr 

M i moderr M ^ moderr M £ moderr M i moderr 



M N i moderr let x= M ; N moderr check M i moderr p(M) £ moderr 

Using this augmented language, unjustified rights amplification is noted as an error. To 
prevent such errors, we modify the typing system to have judgments of the form Y\C \- a M : 
T, where C indicates the accumulated guards on a term which must be discharged before 
the term may be executed; since M is guarded by C, it may include subterms of the form 
}A{ ■ ) when C ^ amplify (A). In addition to adding rules for checked role modifiers, we 
also modify t-grd and t-mod-up. The rule t-mod-up ensures that any amplification is 
justified by C. The rule t-grd allows guards to be used in checking guarded terms; the rule 
is sound since guarded terms must be checked before they are executed. 



(t-grd') (t-mod-up') 

T;C U A\- a M : T T;C h M : (B)[Tj 



C ^ amplify (A) 



T; C h Q -U} [M] : {A}[T] T; C h ]A (M) : (B n A*) [T] 

CUJ)> amplify(A) 



(t-mod-dn-checked) (t- mod-up-checked) 

T;CKM:{B)[T] i{a = 1 T;C h a M : (B)[T] 



T; C h a [A D (M) : {B) [T] then A > B T;C h a ]A D (M) : (B n A*} [T] 

One may not assume that top level terms have been guarded; therefore, let T \- a M : T be 
shorthand for T: k M : T. 



Example 23. The functions domtrans and assign from |Example 21] are not typable using 
this more restrictive system. Recall the definitions: 

domtrans<A, E, B> = Af. Ax. check {A}[unit] ; f {E}[Ag. Ay. B(g y)] x 

assign<E> = Af . Ax. Ay. let g= E (check x) ; g f y 

The amplification of B in domtrans is not justified; neither is the amplification of E in assign. 
The required form is: 

domtrans<A, E, B> = { amplify (B)}l\i. Ax. check {A} [unit] ; f {E}[Ag. Ay. B(g y)] x] 
assign<E> = {amplify(E)} [Af. Ax. Ay. let g= E (check x) ; g f y] 
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The login example must now be modified in order to discharge the guards. Again the 
modifications are straightforward: 

let dtl_oginToUser= check domtrans< Login, UserEXE, User>; 

let dtDaemonToLogin= check domtrans<Daemon, LoginEXE, Login>; 

let assignXUser= check assign<UserEXE> ; 

let assignXLogin= check assign<LoginEXE> ; 

let shell= assignXUser (A. M) ; 

let login= assignXLogin (Apwd . if pwd==" secret" then dtLoginToUser shell unit else . . .) ; 
Daemon (N) 

Thus modified, the program types correctly, but will only execute in a context that dominates 
the four roles amplify (User), amplify (UserEXE), amplify {Login), and amp/«/y(LoginEXE). 
This ensures that domain transitions and assignments are created by authorized code. □ 



Proposition 25 establishes that the typing system is sufficient to prevent role modifica- 



tion errors. The proof of Proposition 25 relies on the following lemma, which establishes the 



relation between typing and mark. 

Lemma 24. IfT;CL\A\- a M:T then T; C h Q mark A (M) : T. 

Proof. By induction on the derivation of the typing judgment, appealing to the definition 
of mark. □ 

Proposition 25. If \- a M : T and A> M -» N then ->(N i moderr) 

Proof Sketch. That -i(M ^ moderr) follows immediately from the definition of role modifi- 
cation error, combined with t-MOD-up' and T-MOD-UP-CHECKED. It remains only to show 
that typing is preserved by reduction. We prove this for the type systems of ISection 31 in 
the next section. The proof extends easily to the type system considered here. The only 
wrinkle is the evaluation rule for check, which is handled using the previous lemma. □ 



6. Proof of Type Safety Theorems 

The proofs for the first and second systems are similar, both relying on well-studied 
techniques [23]. We present proofs for the second system, which is the more challenging of 
the two. 

Definition 26 (Compatibility). Types T and S are compatible (notation T ks S) if T = S 
or T = {A) [R] and S = (B) [R] , for some type R. ~ □ 

The following lemmas have straightforward inductive proofs. 

Lemma 27 (Compatibility). Ifh a T <: T' then T^S iff T' « S. □ 

Lemma 28 (Substitution). IfT h Q M : T and T, x : T h a JV : S, then T h a N{x := M} : S. □ 

Lemma 29 (Bound Weakening). // T, x : S h Q M : T and t- a S' <: S, then T,x : S' h, M : T. 

□ 



A-RBAC: PROGRAMMING WITH ROLE-BASED ACCESS CONTROL 



21 



Lemma 30 (Canonical Forms). 

(1) // h 2 V : T -> S then V has form (Ax. M) where x:Th 2 M :S. 

(2) //ha V : (A)[T] then V has form [M] where h 2 M : T and A= 0. 

(3) IfhV : {A}[T} then V has form {B} [M] where h 2 M : T and B ^ A. 

Proof. 

(1) By induction on derivation of h, V : T -* S. The only applicable cases are T-SUB and 
T-ABS. 

( T-SUB) We know h V : T'^S', where h 2 V : S and h 2 S <: T'^S', s o h 2 T <: T 
and h 2 S <: S' . By the IH, V has form (Ax. M) where x:T \- 2 M : S. Bv ILemma 29l 
and subsumption, x:T' h 2 M : S' . 

(t-abs) Immediate. 

(2) By induction on derivation of h, V : (A)[T], The only applicable cases are T-SUB and 
T-UNIT. 

(t-sub) We know h 2 V : (A')[T'}, where h 2 V : {A)[T] and h 2 (A)[T] <: (A')[T'], so 
h 2 T <: T and A > A'. By the IH, V has form [M] where h 2 M : T and A = 0, so 
A' = 0. By subsumption, h 2 M : T'. 

(t-unit) Immediate. 

(3) By induction on derivation of h, V : {A}[T}. The only applicable cases are T-SUB and 
T-GRD. 

(t-sub) We know h 2 V : {A 1 } [T'] , where h s V : {A}[T} and h {A}[T] <: {A^T'], so 
h 2 T <: T and A > A'. By the IH, V has form {S} [M] where h- 2 M : T and S ^ A, 
so B ^ A'. By subsumption, h 2 M : T. 

(t-grd) Immediate. □ 

Proposition 31 (Preservation). If\- 2 M:T and A\> M ^ N then there exists S such that 
S mT andh N : S and if A> S then A>T. 

Proof. By induction on the derivation of h 2 M : T. The induction hypothesis includes the 
quantification over A, N. For values, the result is trivial; thus we consider only the rules for 
non- values. 

(t-sub) We know h 2 M : T' , where h 2 M : T and h 2 T <: T' , and A > M N. Applying the 
IH to h 2 M : T a nd A > M - » N yields 5 such that h 2 N : 5 and 5 « T and if A > 5 
then A > T. By [L emma lQbl this extends to if A > S then A > T' . In addition, by 
ILemma 27l we have S « T'. 
(t-app) We know h 2 M : T 2 , where h- 2 M : T a T 2 and h 2 AT : T 1; and A > M A" L. 
There are two subcases depending on the reduction rule used in A > M N — » L. 
(M is a value) Bv ILemma 30l M = Ax. M' and x :T a h 2 M' : T 2 . The reduction yields 
L = M'{x := N}. By ILemma 281 hj L : T 2 . The remaining requirements on T 2 are 
immediate. 

(M has a reduction) Therefore i > M -> M' and L = M' N. Applying the IH to 
h 2 M : Tj -» T 2 and A > M -» Af ' yields 5 such that h 2 M' : 5 and 5 w T x -»■ T 2 , which 
implies that S = 7\ -> T 2 . Hence L : T 2 . The remaining requirements on T 2 are 
immediate. 

(t-fix) We know h 2 fix M : T, where h 2 M : T -»• T and A > f ix M -> L. There are two 
subcases depending on the reduction rule used in A > fix M — > L. 
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(M is a value) Bv ILemma 30l M = Xx. M' and x:T h 2 M' : T. The reduction yields 
L = M'{x := M}. By ILemma 281 h, L : T. The remaining requirements on T are 
immediate. 

(M has a reduction) Therefore A o M — » M' and L = fix M'. Applying the IH to 
h 2 M : T -> T and A > M -» M' yields 5 such that h 2 M' : 5 and 5 « T -» T, which 
implies that £ = T -* T. Hence hj L : T, The remaining requirements on T are 
immediate. 

t-chk) We know h 2 check M : (A X )[T], where h 2 M : {Ai}[T], and A > check M -> L. 

There are two subcases depending on the reduction rule used in A > check M — > L. 

(M is a value) Bv ILemma ~30l M = {A 2 }[M'] and h 2 M' : T and A 2 ^ A x . The 
reduction yields L = [M'j and from the reduction we deduce A ^ A 2 , so A ^ A x 
always holds. We assign type hj L : (0)[T], where (0)[T] sa (Ai)[T], and we have 
already shown that A ^ implies A^ A x . 

(M has a reduction) Therefore A > M — > M' and L = check M'. Applying the IH to 
h 2 M : {Ai}[T] and A > M -> M' yields 5 such that h 2 M' : 5 and 5 « {Ai}[T], 
so 5* = {Ai}[T]. Hence hj L : (Ai)[T]. The remaining requirements on (Ai)[T] are 
immediate. 

t-bind) We know h 2 let x= M ; N : (A 1 UA 3 )[T 2 ], where h 2 M : (Ai)[T x ] and x:T x h N : 
(^2)^2], and A let 2= M ; N — > L. There are two subcases depending on the reduction 
rule used in A > let x= M ; N — > L. 

(M is a value) By ILemma 30l M = [M'] an d h 2 M' : T\ and A x = 0, so AiUA 2 =^2- 
The reduction yields L = N{x := M'}. By[L emma 28l h, L : (^2) [^2]- The remaining 
requirements on T 2 are immediate. 

(M has a reduction) Therefore A > M —> M' and L = let x= M' ; N. Applying the IH 
to h 2 M : (Ai)[Ti] and A > M -» M' yields 5 such that h 2 M' : 5 and 5 « (Ai)[2i] 
and if A > S then A > {A X )[T X \. Hence 5 = (A 3 )[Ti], for some A 3 , and A ^ A 3 
implies A^i A x . We deduce h 2 L : (A 3 UA 2 )[T 2 ], where (A 3 UA 2 )[T 2 ] « (iiUij)^]. 
Finally, suppose A > (A 3 U A 2 )[T 2 ], i.e., A ^ A 3 U A 2 , so A ^ A 3 and A ^ A 2 . By 
the above, this entails A A\, so A ~£ A\U A%. Therefore A > {A x U A2)[T 2 ], as 
required. 

T-MOD-UP) We know hj ]A X (M) : (A 2 nA*)[T], where h 2 M : (A 2 )[T], and A > |Ai (M) -» 

L. There are two subcases depending on the reduction rule used in A > f Ai (M) — > L. 

( M is a value ) Therefore L = M and h 2 L : (A 2 )[T], where (A 2 )[T] » (A 2 n A*)[T]. By 
ILemma 30l M = [M'] and hj M' : T and A 2 = 0, and the remaining requirement on 
(A 2 )[T], that A > (A 2 )[T] implies A > (^4 2 n ^)[T], is immediate. 

(M has a reduction) Therefore T^iMD > M ~+ M> and L = T^i C-^')- Applying the 
IH to hj M : (A 2 )[T] and ]A x {a\> M ^ M' yields 5 such that h 2 M' : S and 5 w 
(A 2 )[T], so S = (A 3 )[T] for some A 3 , and if T^iMD ^ s then T^iMD > (^2)^], 
i.e., AUA X ^ A 3 implies A U A x > A 2 . We have h 2 |Ai (M') : (A 3 n A^)[T] and 
(A 3 n A*)[T] w (A 2 n A*)[T]. Finally, if A > (A 3 n A*)[T], then A ^ A 3 n A\, so 
A U A x > (A 3 n A^) U Ai = (A3 U Ai) n 1 = A 3 U Ai. Hence AU A x ^ A 3 , so 
A U A x ^ A 2 , and An A\ = (An A\) U = (A U A x ) U A\^ A 2 U A\. Therefore 
A ^ A 2 n A\ and A > (A 2 n A^)[T], as required. 
t-mod-dn) We know h 2 |A X (M) : (A 2 )[T], where h 2 M : (A 2 )[T], and A > [A x (M) -» L. 

There are two subcases depending on the reduction rule used in A > [A x (M) — > L. 

(M is a value) Therefore L = M and hj L : (A2)[T], and we are done. 
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(Af has a reductio n) Therefore |A X (| A } > Af ->■ Af' and L = J,A X (Af') . By A ^ |A X <\ A \) 
and ILemma 41 we have A > M -> M'. Applying the IH to h 2 M : (A 2 )[T] and 
A > M -» M' yields 5 such that h 2 M' : S and 5 « (A 2 )[T], so S = (A 3 )[T] for some 
A 3 , and if .4 > S then A > (A 2 )[T]. Hence h 2 jAi (Af') : (A 3 )[T], which completes 
the subcase. □ 

Corollary 32. Ifh 2 M:T and A > Af -» V, then A>T. 

Proof. By induction on the length of the reduction sequence A > Af -» V. For the base 
case, Af = V and ILemma 30l implies that A > T, because every non-computation type 
is dominated by any role, and in a computation type T = (B) [S] ILemma 30l tells us that 
B = 0. For the inductive step, there exists N such that A > M — > N and A > AT -» V. By 



Proposition 31 there exists 5 such that JV : 5 and if A > S then A > T. Applying the 



IH to \~ 2 N : S and A > N ^ V yields A > S, hence A > T as required. □ 

Proposition 33 (Progress). For all A, if h 2 M : T then either M is a value, A> Af £ err, 
or there exists N such that A Af — > N . 

Proof. By induction on the derivation of h 2 Af : T. We need only consider the cases when 
Af is not a value. 

(t-sub) We know h 2 M : T', where h 2 M : T and h 2 T <: T' . Immediate by the IH. 

(t-app) We know h 2 Af N : T 2 , where h 2 M : T a -> T 2 and h 2 AT : T a . Apply the IH to 
h 2 M : Ti -> T 2 and role A. If M is a value, then, by ILemma 301 M has form (Ax. L), so 
it>MJV-> L{x := N}. If A> M i err, then A> M N i err. Finally, if A > Af -> L, 
then A> M N ^ L N. 

(t-fix) We know H 2 fix M : T, where h 2 M : T^T. Apply the IH to h 2 M : T^T and role A. 
If M is a value, then, by ILemma" "301 Af has form (Ax. L), so A > fix Af -» L{x := (Ax. L)}. 
If A > M i err, then A > fix M i err. Finally, if A > Af -> f , then A > fix M -> fix L. 

(t-Chk) We know H 2 check M : {Ai)[T\, where h 2 Af : {Ai} [T]. Apply the IH to h 2 M : 
{Ai}[T] and role A. If Af is a value, then, by ILemma 301 there exists B, L such that 
M = {By [L] , so either A > check Af — > [f ] or A > check M ^ err depending on whether 
A > .B holds or not. If A > M i err, then A > check M ^ err. Finally, if A > Af -> f , 
then A > check M — > check L. 

(t-bind) We know h 2 let x=M;N : (A x U A 2 )[T 2 ], where K 2 M : (Ai)[Ti] and x:Ti h 2 
N : (A 2 )[T 2 \. Apply the IH to h 2 Af : {Ai)[Ti] and role A. If M is a value, then, by 
ILemma 301 Af has form [L] , so A > let x= M; AT -> N{x := L}. If A > M i err, then 
A > let x= M; N $ err. Finally, if A > Af ->■ L, then A > let x= M; -> let x= L; AT, 

(t-mod-up) We know h 2 t-Ai (Af) : (A 2 n A*)[T], where h 2 M : (A 2 )[T}. Apply the IH 
to h 2 M : (A 2 )[T] and role T^iMD- If M is a value, then A > (M) -» M. If 
TAidAD > M i err, then A > T^i CM) i err. Finally, if T^iMD > M -» L > then 
A > | At (M) -» f^d). 

(t-mod-dn) We know h 2 |Ai (M) : (A 2 )[T}, where h 2 M : {A 2 )[T}. Apply the IH to 
h 2 M : (A 2 )[T] and role jA^A^. If M is a value, then A > |A X CM) -» Af. If 
|Ai(|AD > Af i err, then A > |A X CM) i err. Finally, if |A X (| A p > Af -» L, then 
A > |A X (Af) -»|A a (L). □ 

Theorem (fl2]l . If\- 2 M:T and A^T, then either A > M — > w or i/iere exists A^ s«c/i i/iaf 
A > Af -» AT and A > N i err. 

Proof. We use a coinductive argument to construct a reduction sequence that is either infinite 
or terminates with a role check failure. When hj Af : T and A ^ T, we know that Af is 
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not a value by ILemma 3Q[ By Proposition 33 , either A > M £ err or there exists N such 
that A > M — > N. In the former case, we are done. In the latter case, using Proposition 31 
there exists S such that h, N : S and if A > S then A > T . However, we know that A^T, 
so A ^ S, as required. □ 



7. Conclusions 

The focus of this paper is programmatic approaches, such as jaas/.net, that use rbac. 
From a software engineering approach to the design of components, RBAC facilitates a sepa- 
ration of concerns: the design of the system is carried out in terms of a role hierarchy with 
an associated assignment of permissions to roles, whereas the actual assignment of users to 
roles takes place at the time of deployment. 

We have presented two methods to aid the design and use of components that include 
such access control code. The first — admittedly standard — technique enables users of 
code to deduce the role at which code must be run. The main use of this analysis is to 
optimize code by enabling the removal of some dynamic checks. The second — somewhat 
more novel — analysis calculates the role that is verified on all execution paths. This 
analysis is potentially useful in validating architectural security requirements by enabling 
code designers to deduce the protection guarantees of their code. 

We have demonstrated the use of these methods by modeling Domain Type Enforce- 
ment, as used in SELinux. As future work, we will explore extensions to role polymorphism 
and recursive roles following the techniques of [8j [4] . 
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